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- The MAILING DATE of this communication appears on the cover sheet with the correspondence address 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1.136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If the period for reply specified above is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1)03 Responsive to communication(s) filed on 08 April 2005 . 
2a)S This action is FINAL. 2b)D This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 
closed in accordance with the practice under Ex parte Quayle, 1935 CD. 11, 453 O.G. 213. 

Disposition of Claims 

4) [3 Claim(s) 21-40 is/are pending in the application. 
4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) M Claim(s) 21-40 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) D The specification is objected to by the Examiner. 

10) E3 The drawing(s) filed on 08 April 2005 is/are: a)S accepted or b)D objected to by the Examiner. 
Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1.85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 

1 1) D The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 1 1 9 

12) D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
a)D All b)D Some * c)D None of: 

1 .□ Certified copies of the priority documents have been received. 

2. D Certified copies of the priority documents have been received in Application No. . 

3. D Copies of the certified copies of the priority documents have been received in this National Stage 
application from the International Bureau (PCT Rule 17.2(a)). 

* See the attached detailed Office action for a list of the certified copies not received. j 

I 

1) Notice of References Cited (PTO-892) 4) □ Interview Summary (PTO-413) H 

2) □ Notice of Draftsperson's Patent Drawing Review (PTO-948) Paper No(s)/Mail Date. . M 

3) □ Information Disclosure Statement(s) (PTO-1449 or PTO/SB/08) 5 ) D Notice of Informal Patent Application (PTO-152) /^fl 
Paper No(s)/Mail Date . 6) □ Other: . 

U.S. Patent and Trademark Off ice " ~" 

PTOL-326 (Rev. 1 -04) Office Action Summary Part of Paper No./Mai! Date 20050722 



Application/Control Number: 09/709,486 Page 2 

Art Unit: 2624 

DETAILED ACTION 
Response to Amendment 
L Claims 21 - 40 are pending, claims 1 - 20 are canceled 

2. The drawings were received on 4/8/05. These drawings are accepted. 

3. Oath/Declaration dated 4/8/05 is accepted. 

4. Specification replacement paragraphs dated 4/8/05 are accepted. 

5. Previous rejections withdrawn due to cancellation of claims. New rejections applied to 
new claims. 

Claim Rejections - 35 USC §103 
The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

6. Claims 21, 27 - 29, and 36 - 40 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Salas et al. (US 6314408) in view of Lindhorst et al. (US 6889379). 

Regarding claims 21 and 28 . Salas teaches a method of uploading (col. 1 1 lines 39-46; 
610 of Fig. 6; col. 12 line 44 which is included in the upload process discussed in col. 12 line 38 
-col. 13 line 53 ^) a print file (Fig. 4 ref. no. 490, 486, 488; col. 5 lines 13-16, wherein these are 
files that can be printed) from a client (12', Figs. 1 and 3) to a server (14, Fig. 1) via a network 
(col. 1 lines 15-20, col. 2 lines 40-42, Fig. 1 shows the networked computers). 

Further, the specific uploading includes: 
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Client generates an upload begin request, it is transferred to the server, and the server 
receives it (col. 12 lines 45-47, wherein the dragging creates the command that is sent to the 
server in col. 12 lines 62-65 to indicated an upload request) before actually uploading occurs 
(command 710 is sent before file is transferred at 712, Fig. 7). 

Server executes upload begin request (col. 13 line 1), launches the object (col. 13 lines 1-2), 
creates an id for the object and associated file (col. 13 lines 2 and 7-14, wherein metadata 
describing the file is created and the file, object, and metadata are associated, which must be 
done with some kind of code identification). 

The server must transmit the upload begin response and the client must receive it (with the 
identification) for the below steps to take place. 

Client generates, transmits, and server receives: upload request, identification, and data 

(after the new object is created with associated identifying metadata the file is uploaded using 
HTTP [col. 13 lines 1-3] - the HTTP uploading process includes the HTTP POST command 
[upload request; col. 13 lines 40-53] that includes the identification [col. 13 line 46, wherein 
identification of the data must be included and take place in order to associate it with the 
created object at the server] and the file data [col. 13 line 48]). 
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While Salas teaches using web standards (HTML, Java, ActiveX, Internet Explorer, 
HTTP, ODBC) and building web pages (col. 6 line 19) and in col. 12 lines 48-50 allows the 
uploading process to be completed by any suitable Web process and transmission is done via 
HTTP (col. 13 line 3, step 712 of Fig. 7), Salas does not specifically teach that active server page 
(ASP) technology is used in the web environment. 

Lindhorst teaches using ASP technology in web environments (Figs. 1 1 and 12, their 
descriptions; col. 2 lines 11-16 and lines 25-67 and clearly throughout), including those using 
objects (col. 5 line 26 and throughout) as Salas does as well as teaching using the HTTP POST 
command in an ASP environment (col. 4 lines 11-16 and 31-51; col. 18 lines 40-60). 

It would have been obvious to one of ordinary skill in the art to use ASP standard 
technology in the web environment of Salas. The motivation for doing so would have been to 
use an industry standard to allow the invention to be accessible and useable by in ASP 
environments and by other technologies ASP. Further, the HTTP POST command used to 
upload files in ASP as taught in Lindhorst and thus is a clear indication that it would have been 
obvious. Also, ASP was developed and introduced by Microsoft and was known to run on 
Microsoft servers, and being compatible with Microsoft servers would have been a definite 
advantage. 

Regarding claims 27 and 29 . which depend from claims 21 and 28, Salas teaches the 
client receiving the request (dragging and dropping into the browser) and generates and transmits 
the request as discussed in the rejection to claim 21 (col. 12 lines 45-47, wherein the dragging 
creates the command that is sent to the server in col. 12 lines 62-65 to indicated an upload 
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request) before actually uploading occurs (command 710 is sent before file is transferred at 712, 
Fig. 7). 

Regarding claims 36 and 38 . Salas teaches a method of uploading (col. 1 1 lines 39-46; 
610 of Fig. 6; col. 12 line 44 which is included in the upload process discussed in col. 12 line 38 
- col. 13 line 53 ) a print file (Fig. 4 ref no. 490, 486, 488; col. 5 lines 13-16, wherein these are 
files that can be printed) from a client (12', Figs. 1 and 3) to a server (14, Fig. 1) via a network 
(col. 1 lines 15-20, col. 2 lines 40-42, Fig. 1 shows the networked computers). 

Further, the specific uploading includes: 

Client generates an upload begin request, it is transferred to the server, and the server 
receives it (col. 12 lines 45-47, wherein the dragging creates the command that is sent to the 
server in col. 12 lines 62-65 to indicated an upload request) before actually uploading occurs 
(command 710 is sent before file is transferred at 712, Fig. 7). 

Server executes upload begin request (col. 13 line 1), launches the object (col. 13 lines 1-2), 
creates an id for the object and associated file (col. 13 lines 2 and 7-14, wherein metadata 
describing the file is created and the file, object, and metadata are associated, which must be 
done with some kind of code identification). 

The server must transmit the upload begin response and the client must receive it (with the 
identification) for the below steps to take place. 
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Client generates, transmits, and server receives: upload request, identification, and data 

(after the new object is created with associated identifying metadata the file is uploaded using 
HTTP [col. 13 lines 1-3] - the HTTP uploading process includes the HTTP POST command 
[upload request; col. 13 lines 40-53] that includes the identification [col. 13 line 46, wherein 
identification of the data must be included and take place in order to associate it with the 
created object at the server] and the file data [col. 13 line 48]). 

While Salas teaches using web standards (HTML, Java, ActiveX, Internet Explorer, 
HTTP, ODBC) and building web pages (col. 6 line 19) and in col. 12 lines 48-50 allows the 
uploading process to be completed by any suitable Web process and transmission is done via 
HTTP (col. 13 line 3, step 712 of Fig. 7), Salas does not specifically teach that active server page 
(ASP) technology is used in the web environment. 

Lindhorst teaches using ASP technology in web environments (Figs. 1 1 and 12, their 
descriptions; col. 2 lines 11-16 and lines 25-67 and clearly throughout), including those using 
objects (col. 5 line 26 and throughout) as Salas does as well as teaching using the HTTP POST 
command in an ASP environment (col 4 lines 11-16 and 31-51; col. 18 lines 40-60). 

It would have been obvious to one of ordinary skill in the art to use ASP standard 
technology in the web environment of Salas. The motivation for doing so would have been to 
use an industry standard to allow the invention to be accessible and useable by in ASP 
environments and by other technologies ASP. Further, the HTTP POST command used to 
upload files in ASP as taught in Lindhorst and thus is a clear indication that it would have been 
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obvious. Also, ASP was developed and introduced by Microsoft and was known to run on 
Microsoft servers, and being compatible with Microsoft servers would have been a definite 
advantage. 

Regarding claims 37 . which depend from claim 36, Salas teaches the client receiving the 
request (dragging and dropping into the browser) and generates and transmits the request as 
discussed in the rejection to claim 21 (col. 12 lines 45-47, wherein the dragging creates the 
command that is sent to the server in col. 12 lines 62-65 to indicated an upload request) before 
actually uploading occurs (command 710 is sent before file is transferred at 712, Fig. 7). 

Regarding claims 39 and 40 . the method steps of method claims 21 and 28 are the same 
as those of claims 39 and 40. Further the server and client of Salas are computing devices 
known in the art to include memory to store, and processors to execute, instructions. Therefore, 
claims 39 and 40 are rejected for the same reasons stated above in the rejections of claims 21 and 
28. 

7. Claims 22 - 26 and 3 1 - 35 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Salas and Lindhorst as applied to claims 21 and 28 above, and further in view of Tech-Pro 
TCP/IP Basics (http://www.tech-pro.net/intro_tcp.html). 

Regarding claims 22 and 31 . which depends from claims 21 and 28, Salas teaches the 
data uploaded is stored in the server database (col. 2 lines 43-67) and in a packet environment 
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such as that of Salas (www, http), the response of a successfully completed packet must be 
transmitted back to the client to determine whether or not to retry the failed packet. 

Tech-Pro reference is brought in to show proof of packet TCP/IP transmission specifics 
as claimed as inherent to that of the Salas reference. The whole article is supportive, but 
Examiner wishes to bring applicant 's attention to Transmission Control Protocol, Making a 
connection, Data Transmission, and Error Correction headings and their description. Under 
these headings, the acknowledgements (responses and requests) as well as error checking and 
transmission retries are discussed and explained as inherently part of the TCP/IP World Wide 
Web system and thus would have been inherent to the transferring taught in the WWW/HTTP 
system of Salas. 

Regarding claims 23 - 25. 33-35 . which depend from claim 31, Salas further teaches 
the interactions between client and server to determine transmission/connection errors and 
failures and having to try again later (col. 1 1 lines 19-24, wherein trying later would be a 
resume) including that transmitting can have c too many errors' (predetermined number) and 
cause a interaction failure (col. 1 1 line 22). Further, it is known (and thus Salas must provide in 
the World Wide Web/http networks) for packets transmitted via networks to have checksums in 
order to indicate errors as well as sequence numbers and acknowledge signals to indicate 
whether a certain packet (part of a file) has not been transmitted correctly. 
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Regarding claims 26 and 32 . which depend from claims 21 and 31, Salas teaches 
storing the file in a network database (col. 2 lines 43-67) and that the server knows the upload is 
complete (which must happen through some indication from the client) in order to update 
metadata associated with object and file (col. 12 lines 27-30). 

8. Claim 30 is rejected under 35 U.S.C. 103(a) as being unpatentable over Salas and 
Lindhurst as applied to claim 28 above, and further in view of Osada et al. (US 6600569). 

Regarding claim 30 . which depends from claim 28, Salas teaches print files that are 
known to be generated by applications (Fig. 4, ref. no. 486, 488, 490, wherein notes generally 
created by NOTEPAD or WORDPAD, the others being known as created in MICROSOFT 
EXCEL and WORD). 

Salas does not specifically teach that the print file is a file generated by a print driver by a 
print command. 

Osada teaches a system for uploading print files to a server (Fig. 15 shows the system, 
client 109 and server [110, wherein the printer performs all standard server functionality since 
file reception, storage, analysis, and dispatch are performed by it] - see also the description of 
Fig. 15 for more details) including the ability to transfer print files directly from applications 
(1501 to 1507, Fig. 15) and print files that have been generated by the printer driver 1502 (1501 
to 1502 to 1507, Fig. 15). Further discussion of Osada can be read in previous Action. 

It would have been obvious to one of ordinary skill in the art that not only the editing and 
viewing functions would want to be shared in the system of Salas, but also printing options. 
Thus, the remote users could view and print the file directly without having a local print driver. 
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Conclusion 

9. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

US-6427169, Elzur, 7-30-2002: teaches parsing a packet header. 

US-6857009, Ferreria et al., 2-15-2005: teaches system and method for network access 

without reconfiguration, specifically noted is Fig. 17. 
US-6430607, Kavner, 8-6-2002: teaches system and method for performing remote 

requests with an on-line service network, specifically noted is col. 32-33. 

10. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1 . 136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 . 136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Lucas Divine whose telephone number is 571-272-7432. The 
examiner can normally be reached on Monday - Friday, 7:30am - 5:00pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, David Moore can be reached on 571-272-7437. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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